3GPP supports several features that enable a user equipment (UE) to sleep for longer periods in order to conserve power. Power Savings Mode (PSM) and extended Idle Mode DRX (eDRX) are features that allow the UE to sleep for relatively long periods of time. While in a “Sleep” state, a given UE typically does not listen for pages from the network, and thus the UE is unreachable for mobile terminated (MT) communications. Extended S-GW buffering is a feature where MT data that targets a UE that is in a long sleep period can be buffered in the S-GW until the UE is listening to the network. Reachability Notifications is a feature that allows a service capability server or application server (SCS/AS) to be notified when the UE is available for MT communications.
Power Savings Mode (PSM) is a UE state that was introduced in 3GPP Release 12. The PSM feature is defined in 3GPP TS 23.682 (“Architecture enhancements to facilitate communications with packet data networks and applications”) and sections 4.3.22 and 4.3.5.2 of 3GPP TS 23.401 (“General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”).
The objective of the Power Saving Mode (PSM) feature is to reduce power consumption at the UE. A UE under PSM mode is similar to power-off, but the UE remains registered with the network and there is no need to re-attach or re-establish PDN connections. The PSM feature introduces a new timer called ‘Active Time’, which indicates the time during which the UE remains reachable before going to PSM. The UE starts the Active Time when it transitions to idle mode, and is available for any mobile terminated requests during Active Time. When the Active timer expires, the UE deactivates its Access Stratum functions and enters PSM. In PSM, due to the deactivation of Access Stratum functions, the UE stops idle mode procedures, but continues to run any NAS timers that may apply (e.g. the periodic TAU timer).
Generally, when a UE supports PSM, it indicates to the CN that it wants to use PSM by providing an Active Time value during the Attach or TAU/RAU procedures. If the network supports PSM and wants to allow the UE to use PSM, it confirms usage of PSM by allocating an Active Time Value to the UE. The network determines the Active Time by considering the UE's requested value, and network configuration and policies. In some cases, if the UE wishes to modify the Active Time value, then the UE requests the value it wants in the next periodic TAU/RAU procedure. The UE remains in PSM mode until a mobile originated event (e.g., periodic RAU/TAU, mobile originated data or detach) requires the UE to initiate any procedure towards the network.
Typically PSM is intended to be used for UEs that are expecting infrequent mobile originating and terminating services, and for UEs that can accept a corresponding latency in the mobile terminating communication. This implies that any application that wants to use PSM needs to request an Active Time that is long enough to allow for potential mobile terminated service or data delivery.
Turning to extended discontinuous reception (DRX), a UE that is using extended Idle Mode DRX (Extended DRX or eDRX) has longer time periods between paging occasions (POs). At each paging occasion, the UE listens to the network for a page. A page indicates to the UE that the network may have data to send to the UE, so its RRC connection should be activated so that it can receive data. Assuming that the UE is not paged, the UE may enter a sleep state (reduced power consumption) in between paging occasions. In some cases, the time between eDRX paging occasions may be configured to be as long as approximately 45 minutes.
The UE may request to use eDRX during an attach or tracking area update (TAU) procedure. The attach or TAU request may be used by the UE to request to use specific eDRX parameters. The network may respond by accepting the UE's eDRX parameters, rejecting the UE's request to use eDRX, or accepting the UE's request to use eDRX while providing different eDRX parameters.
In some cases, an S-GW may support extended buffering of MT Data when a UE is using sleep modes, such as PSM or eDRX for example. The S-GW may buffer MT data until the UE exits PSM (by performing a TAU) or until the UE's next paging occasion. The SCEF may provide API's to the SCS/AS. The API's may allow the SCS/AS to configure the S-GW's use of extended buffering for a UE. For example, the API's may allow the SCS/AS to configure how many MT packets may be buffered, and how long the packets should remain in the buffer before being discarded. Alternatively, for example, the UE's use of extended S-GW buffering may be configured in the UE's subscription information by the network operator. Currently, when an SCS/AS sends a packet to a UE and the packet is stored in the S-GW buffer, the SCS/AS receives no acknowledgement (or confirmation) from the MCN that the packet is in the buffer.
Turning now to Reachability Notifications, the SCEF may expose API's to the SCS/AS that allow the SCS/AS to request to be notified when the UE is reachable or will soon become reachable. For example, the MCN may notify the SCS/AS when the UE attaches, exits PSM by performing a TAU, or when the UE's paging occasion is approaching. If an SCS/AS uses reachability notifications to coordinate its communication with a UE, it may avoid the use of PSM. Reachability notifications are further described in TS 23.682.
The SCEF may expose API's to the SCS/AS that allow the SCS/AS to schedule, or negotiate, a background data transfer with the MCN. The API may allow the SCS/AS to indicate the number of UE's in the transfer, the volume of data that will be sent, and geographic location of the UE's. The MCN may then provide the SCS/AS with a time when the data transfer may be performed. Background data transfers are described further in TS 23.682 and 3GPP TS 23.203 (“Policy and charging control architecture”).
Turning now to current approaches to retransmissions in transport layer and application layer protocols, some transport layer protocols may require that some packets be acknowledged. For example, transmission control protocol (TCP) is a protocol that requires that the recipient of a packet send an acknowledgement. If the sender does not receive an acknowledgement within a timeout period (e.g., 1 second), then the sender will retransmit the packet. The sender may increase the size of the timeout and continue attempting to send the packet until it receives an acknowledgement. The TCP allows the receiver to identify packets that have been received in duplicate so that duplicate packets can be discarded. In some cases, a sender does not need to wait for a packet to be acknowledged before sending another packet; multiple packets may be in transit at the same time.
CoAP is an example of an application layer protocol that may be configured so that some packets must be acknowledged. Similar to TCP, CoAP may be configured to have a timeout period, after which unacknowledged packets will be retransmitted. The CoAP protocol also allows the receiver to identify packets that have been received in duplicate so that duplicate packets can be discarded. In some cases, a sender does not need to wait for a packet to be acknowledged before sending another packet; multiple packets may be in transit at the same time.
Referring to FIG. 1, an example overview of Network Functions Virtualization (NFV) is depicted. By way of an overview, NFV aims to transform the way that network operators architect networks. In particular, IT virtualization technology is being used to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which can be located in data centers, network nodes, and in the end user premises. Network functions (e.g., mobility management, session management, QoS) can be implemented in software, and the network functions can run on a range of industry standard server hardware. The functions can be moved to, or instantiated in, various locations in the network as required, without the need for installation of new equipment. FIG. 1 illustrates one example of an architectural framework for NFV that has been provided by ETSI.
It is recognized herein that NFV may be applied to any data plane packet processing and control plane function in mobile and fixed networks. Examples include, presented without limitation:                Switching elements (e.g., BNG, CG-NAT, routers)        Mobile network nodes (e.g., HLR/HSS, MME, SGSN, GGSN/PDN-GW, RNC, eNodeB)        Functions contained in home routers and set top boxes to create virtualized home environments        Converged and network-wide functions (e.g., AAA servers, policy control, and charging platforms        Application-level optimization (e.g., CDNs, Cache Servers, Load Balancers, Application Accelerators)        Security functions (e.g., firewalls, virus scanners, intrusion detection systems, spam protection        
It is recognized herein that applying NFV may provide various benefits to network operators, which may contribute to dramatic changes in the telecommunications industry landscape. For example, and without limitation, it is recognized herein that NFV may provide for:                Reduced equipment costs and reduced power consumption through consolidating equipment and exploiting the economies of scale of the IT industry.        Increased velocity of Time to Market by minimizing the typical network operator cycle of innovation.        The possibility of running production, test and reference facilities on the same infrastructure provides more efficient testing and integration, reducing development costs and time to market.        Targeted service introduction based on geography or customer sets. Services can be rapidly scaled up/down as required.        The enablement of a wide variety of eco-systems (encouraging openness).        Optimized network configuration and/or topology in near real time based on the actual traffic/mobility patterns and service demand.        The support of multi-tenancy, thereby allowing network operators to provide tailored services and connectivity for multiple users, applications, internal systems, or other network operators, which may co-existing on the same hardware with appropriate secure separation of administrative domains.        Reduced energy consumption by exploiting power management features in standard servers and storage, as well as workload consolidation and location optimization.        
FIG. 2 is an example (from ETSI GS NFV 002) of an end-to-end Network Service with VNFs and nested forwarding graphs. FIG. 2 illustrates the concept of a Virtualized Network Function Forwarding Graph (VNF-FG). A VNF-GW describes how a set of VNF's are connected to provide a service.
Network Slicing, such as described in the Next Generation Mobile Network (NGMN) Alliance, “Description of Network Slicing Concept”, is a mechanism that can be used by mobile network operators to support multiple virtual networks behind the air interface across the fixed part of the mobile operator's network (both backhaul and core network). This involves ‘slicing’ the network into multiple virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables the operator to create networks that are customized to provide optimized solutions for different market scenarios that demand diverse requirements, for example, in the areas of functionality, performance, and isolation. FIG. 3 shows an example conceptual architecture of network slicing. It will be understood that the different types of shading in FIG. 3 indicate the different network slice instances or subnetwork slice instances.
3GPP is designing a 5G network and is considering whether to incorporate the network slicing technology, which may be a good fit for the 5G network because the 5G use cases (e.g., massive IoT, critical communications, and enhanced mobile broadband) demand very diverse and sometimes extreme requirements. The current architecture utilizes a relatively monolithic network and transport framework to accommodate a variety of services, such as, for example, mobile traffic from smart phones, OTT content, feature phones, data cards, and embedded M2M devices. It is anticipated that the current architecture is not flexible and scalable enough to efficiently support a wider range of business needs when each has its own specific set of performance, scalability, and availability requirements. Furthermore, it is recognized herein that the introduction of new network services should be made more efficient. Nevertheless, several use cases are anticipated to be active concurrently in the same operator network, thus requiring a high degree of flexibility and scalability of the 5G network.
With respect to power saving modes in the 5G network, the 5G network may support some type of power savings mode (or UE state), for example, where the UE turns off certain functions to reduce power consumption and does not listen to the Mobile Core Network (MCN) for pages. If the UE does not listen to the MCN for pages while in a power saving mode (or state) it is not reachable for mobile terminated (MT) communication.
It is recognized herein that when user equipments (UEs) are allowed to enter long periods of sleep, such as when PSM and/or eDRX are used, situations may arise in which the UE is not reachable, and the network or a third Party Server may need to contact the UE for a mobile terminated event.